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DETAILED ACTION 

This Office action is in response to Applicant's amendment and request for 
reconsideration filed on February 28, 2006. Claims 2-47 are presented for further examination. 
All independent claims have been amended. 

Response to Arguments 
1. In response to Applicant's request for reconsideration filed on February 28, 2006, the 
following factual arguments are noted: 

a. Block failed to disclose a network interface controller having a completion 
processing unit. 

b. The prior art of record failed to disclose the claimed multiple end-to-end contexts at 
both the source endnode and destination endnodes. 



In considering (a), Examiner respectfully disagrees with Applicant's argument. Block 
clearly disclosed that the processor and memory of the computing system executing Block's 
disclosed applications can control the network interfaces 193 of figure 1 (Block Col 8, lines 52- 
56). In other words, the processor and memory of a computer in Block's system both controls 
the network interfaces and also contains the completion processing unit functionality. Thus, 
Block disclosed that network interface controller has a completion processing unit. 



In considering (b), Examiner respectfully disagrees with Applicant's argument. This 
argument was previously addressed in the final rejection mailed July 27, 2005 pgs 9-10. 
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Furthermore this argument has not been persuasive and continues not to be persuasive. Rather 
than Applicant continuing to belabor the same points Applicant is encouraged to file an appeal so 
that this issue may be pushed to the Board of Patent Appeals and Interferences for resolution. 

Claim Rejections - 35 USC §103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

2. Claims 2-18, 22, 25-41, and 45 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Request for Comment 793 (Transmission Control Protocol, hereinafter 
RFC 793) and Mockapetris (Analysis of Reliable Multicast Algorithms for Local Networks, 
Paul Mockapetris) and Block et al. (U.S. Patent Number 6,192,417; hereinafter Block). 

3. Regarding claim 2, RFC 793 discloses a distributed computer system comprising: 

□ a source endnode including: 

a. a source process which produces message data (pg 7, last U continued on pg 8 
and pg 24, last \ first sentence); 

b. a send work queue having work queue elements that describe the message 
data for sending (pg 24, last and pg 41, 3 rd % last sentence); 

□ destination endnode including: 

a. a destination process (pg 7, last ^ continued on pg 8); 



Application/Control Number: 09/980,761 Page 4 

Art Unit: 2153 

b. a receive work queue having work queue elements that describe where to 
place incoming message data (pg 7, last K continued on pg 8); 

□ communication fabric providing communication between the source endnode and the 
destination endnode (inherent; pg 7, last U continued on pg 8); and 

□ an end-to-end context at the source endnode and the destination endnode storing state 
information to ensure the reception and sequencing of message data sent from the 
source endnode to the destination endnode thereby permitting reliable datagram 
service between the source endnode and the destination endnode (Section 2.6 
beginning on pg 9). 

However, RFC 793 fails to disclose 1) reliable multicast to a group of destination 
endnodes wherein the reliable multicast comprise a series of replicated unicasts to each endnode 
and 2) a network interface controller having a completion processing unit for generating a 
completion event to the source process in response to an indication that a predetermined 
percentage of destination endnodes in the multicast group have reliably received a selected 
amount of message data multicast from the source endnode. 

With regard to point 1 , reliable multicasting to a group of recipients through a series of 
replicated packets was well known in the art at the time of invention, as evidenced by 
Mockapetris. In a related art Mockapetris teaches a reliable multicasting method where the 
sender sends a separate (replicated) message to each destination endnode and receives an 
acknowledgement of receipt from each endnode separately (pg 153 Simulation algorithms, 1st ^|). 
Mockapetris further discloses that the sender maintains the multicast group of destination 
endnodes as a list (pg 153 Simulation algorithms, 1st H). It would have been obvious to one of 
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ordinary skill in the art at the time of invention to add the multicast functionality disclosed by 
Mockapetris to the one-to-one transmission system disclosed by RFC 793 in order to provide a 
straightforward method for reliable one-to-many transmission (pg 153 Simulation algorithms, 1st 

In the combined Mockapetris and RFC 793 system, all one-to-one transmission 
capabilities defined in the RFC 793 are expanded to a one-to-many (multicast) transmission 
capability since the one-to-many transmission is simply a series of replicated one-to-one 
transmissions to each multicast member endnode, as disclosed by Mockapetris (Cited above). 

With regard to point 2, while RFC 793 discloses generating a completion event (TCP-to- 
user signals) for each endnode that acknowledges a received frame (pg 41, 5th ^) neither RFC 
793 nor Mockapetris specifically recited a network interface controller having a completion 
processing unit for generating a completion event to the source process in response to an 
indication that a predetermined percentage of destination endnodes in the multicast group have 
reliably received a selected amount of message data multicast from the source endnode. 
Nonetheless it was widely known in the art at the time of the invention to notify application 
source processes that make multicast requests the status of such requests, as evidenced by Block. 
In a similar multicasting system, Block disclosed multicasting messages to a group of nodes (Col 
9, lines 28-34). Like RFC 793 and Mockapetris, Block relies on acknowledgments from each 
node in the multicast group to determine which nodes have reliably received each multicast 
message (Col 15, lines 51-57 or Col 16, lines 8-1 1). In Block's system the source process that 
submits the multicast request can receive a completion event (notification) when a predetermined 
percentage of nodes (i.e. all nodes in the multicast group) have reliably received the multicast 
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message (see inter alia Col 13, lines 40-43 and Col 16, lines 8-11, 18-19). This notification 
scheme allows the source process that submits a multicast request to be notified of the multicast 
request status. Additionally Block disclosed that the notification scheme may be implemented 
using a network interface controller (i.e. the processor and memory of the computing system 
executing Block's disclosed applications, see inter alia Block Col 8, lines 53-56). Thus, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to incorporate 
the completion event notification scheme, as disclosed by Block, within the combined RFC 793 
and Mockapetris system, so that application processes which use the combined RFC 793 and 
Mockapetris multicast system are apprised of the status of their multicast requests. 

4. Regarding claim 25, RFC 793 discloses a method of sending message data in a distributed 
computer system, the method comprising: 

□ producing message data with a source process at the source endnode (pg 7, last U 
continued on pg 8 and pg 24, last % first sentence); 

a describing the message data for sending with work queue elements in a send work 
queue at the source endnode (pg 24, last H and pg 41, 3 rd % last sentence); 

□ describing where to place incoming message data with work queue elements in a 
receive work queue at the destination endnode (pg 7, last U continued on pg 8); 

□ storing state information in an end-to-end context at the source endnode and the 
destination endnode to ensure the reception and sequencing of message data sent from 
the source endnode to the destination endnode (Section 2.6 beginning on pg 9); and 
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□ reliably sending data including performing a unicast of message mdata though the 
send work queue and the end-to-end context at the source endnode to the receive 
work queue and end-to-end context portion at the destination endnodes (Section 2.6 
beginning on pg 9). 

However, RFC 793 fails to disclose 1) reliable multicast to a group of destination 
endnodes wherein the reliable multicast comprise a series of replicated unicasts to each endnode 
and 2) generating a completion event to the source process in response to an indication that a 
predetermined percentage of destination endnodes in the multicast group have reliably received 
a selected amount of message data multicast from the source endnode. 

With regard to point 1, reliable multicasting to a group of recipients through a series of 
replicated packets was well known in the art at the time of invention, as evidenced by 
Mockapetris. In a related art Mockapetris teaches a reliable multicasting method where the 
sender sends a separate (replicated) message to each destination endnode and receives an 
acknowledgement of receipt from each endnode separately (pg 153 Simulation algorithms, 1st H). 
Mockapetris further discloses that the sender maintains the multicast group of destination 
endnodes as a list (pg 153 Simulation algorithms, 1st U). It would have been obvious to one of 
ordinary skill in the art at the time of invention to add the multicast functionality disclosed by 
Mockapetris to the one-to-one transmission system disclosed by RFC 793 in order to provide a 
straightforward method for reliable one-to-many transmission (pg 153 Simulation algorithms, 1st 

ID- 

In the combined Mockapetris and RFC 793 system, all one-to-one transmission 
capabilities defined in the RFC 793 are expanded to a one-to-many (multicast) transmission 
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capability since the one-to-many transmission is simply a series of replicated one-to-one 
transmissions to each multicast member endnode, as disclosed by Mockapetris (Cited above). 

With regard to point 2, while RFC 793 discloses generating a completion event (TCP-to- 
user signals) for each endnode that acknowledges a received frame (pg 41, 5th neither RFC 
793 nor Mockapetris specifically recited generating a completion event to the source process in 
response to an indication that a predetermined percentage of destination endnodes in the 
multicast group have reliably received a selected amount of message data multicast from the 
source endnode. Nonetheless it was widely known in the art at the time of the invention to notify 
application source processes that make multicast requests the status of such requests, as 
evidenced by Block. In a similar multicasting system, Block disclosed multicasting messages to 
a group of nodes (Col 9, lines 28-34). Like RFC 793 and Mockapetris, Block relies on 
acknowledgments from each node in the multicast group to determine which nodes have reliably 
received each multicast message (Col 15, lines 51-57 or Col 16, lines 8-1 1). In Block's system 
the source process that submits the multicast request can receive a completion event 
(notification) when a predetermined percentage of nodes (i.e. all nodes in the multicast group) 
have reliably received the multicast message (see inter alia Col 13, lines 40-43 and Col 16, lines 
8-11, 18-19). This notification scheme allows the source process that submits a multicast request 
to be notified of the multicast request status. Thus, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to incorporate the completion event 
notification scheme, as disclosed by Block, within the combined RFC 793 and Mockapetris 
system, so that application processes which use the combined RFC 793 and Mockapetris 
multicast system are apprised of the status of their multicast requests. 
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5. Regarding claims 3 and 26, RFC 793 discloses the source endnode including a network 
interface controller which packetizes the message data into frames (Section 2.2 beginning on pg 
7). 

6. Regarding claims 4 and 27, RFC 793 discloses the system wherein the destination endnodes 
each include a network interface controller which acknowledges receipt of frames sent from the 
source endnode (pg 6 Reliability section). 

7. Regarding claims 5 and 28, RFC 793 discloses the system wherein the network interface 
controller and the end-toend context portion in the destination endnode ensures strong ordering 
of received frames sent from the source endnode, such that the frames are received in a same 
defined order as transmitted from the source endnode (pg 6 Reliability section). 

8. Regarding claims 6 and 29, RFC 793 discloses the system wherein the source endnode 
retransmits frames that are not successively acknowledged in the reliable multicast service (pg 6 
Reliability section). 

9. Regarding claims 7 and 30, Mockapetris discloses the system wherein the network interface 
controller in the source endnode includes hardware which replicates frames to be provided in the 
series of unicasts (inherent, pg 153 Simulation algorithms, 1st ft). 

10. Regarding claims 8 and 31, Mockapetris discloses the system wherein the source endnode 
includes software verbs which perform the series of unicasts as a series of individual sequenced 
message send operations (pg 153 Simulation algorithms, 1st U). 

1 1 . Regarding claims 9 and 32, Mockapetris discloses the system wherein changes in 
composition of the endnodes participating in the multicast group are communicated to all 
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endnodes participating in the multicast group (inherent, each sender maintains a list of multicast 
members and each member can be a sender; pg 153 Simulation algorithms, 1st U). 

12. Regarding claims 10 and 33, Mockapetris discloses the system wherein the source endnode 
and each destination endnode maintains a list of destination addresses for all other endnodes 
participating in the multicast group (pg 153 Simulation algorithms, 1st 

13. Regarding claims 1 1-12 and 34-35, RFC 793 discloses generating cumulative and per frame 
acknowledgments (pg 20, last U continued on to pg 21). 

14. Regarding claims 13-16 and 36-39, RFC 793 discloses gathering and counting 
acknowledgements from endnodes using a completion processing unit containing a completion 
queue (retransmission queue) (pg 21, first sentence below Functional Specification heading; pg 
22 top fl). RFC 793 further discloses informing the source process (through TCP-to-user signals) 
of an operation status of frames (pg 41, 5th U). 

15. Regarding claims 17-18 and 40-41, RFC 793 discloses generating a completion event (TCP- 
to-user signals) for each endnode that acknowledges a received multicast frame (pg 41, 5th 
However, both Mockapetris and RFC 793 fail to teach generating a completion event when a 
certain percentage of endnodes have received the multicast frame. The Examiner takes Office 
Notice that it was well known in the computer networking art at the time of invention to generate 
events to a source process based on the percentage of completion (0% to 100%) for a given task. 
It would have been obvious to one of ordinary skill in the art at the time of invention to generate 
a completion event when a certain percentage of endnodes received the multicast frame in order 
to alert the host process of the multicast completion status. 
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16. Regarding claims 22 and 45, RFC 793 discloses the system wherein the completion 
processing unit includes a timing window, wherein expiring of the timing window without 
necessary conditions for a completion event for a corresponding multicast frame occurring 
indicates that any missing acknowledgments art to be tracked and resolved (pg 10, 1st %). 

17. Claims 19-21 and 42-44 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Request for Comment 793 (Transmission Control Protocol, hereinafter RFC 793) and 
Mockapetris (Analysis of Reliable Multicast Algorithms for Local Networks, Paul 
Mockapetris) and Block et al. (U.S. Patent Number 6,192,417; hereinafter Block), as 
applied to the claims above, and further in view of Aldrich (USNET post, John M. Aldrich 
Oct 16 1997). 

18. Regarding claims 19 and 42, as discussed above RFC 793 discloses tracking ACKs from 
each endnode however, RFC 793 fails to teach using a bit-mask array for such tracking. 
Nevertheless, the use of bit-mask arrays to track events was well known in the art at the time of 
invention, as evidenced by Aldrich. In a related art, Aldrich discloses using a bit-mask array as a 
set of flags, which can be set and unset using bitwise operators (pg 2, top fl). It would have been 
obvious to one of ordinary skill in the art at the time of invention to use a bit-mask array to track 
acknowledgements from endnodes in order to minimize memory consumption by only using a 
single bit to track each acknowledgement. 

19. Regarding claims 20-21 and 43-44, RFC 793 discloses generating a completion event (TCP- 
to-user signals) for each endnode that acknowledges a received multicast frame (pg 41, 5th ft). 
Further as discussed with respect to claims 2 and 25, Block disclosed generating a completion 
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event when a certain percentage of endnodes have received the multicast frame (see inter alia 
Col 13, lines 40-43 and Col 16, lines 8-11, 18-19). 

20. Claims 23-24 and 46-47 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Request for Comment 793 (Transmission Control Protocol, hereinafter RFC 793) and 
Mockapetris (Analysis of Reliable Multicast Algorithms for Local Networks, Paul 
Mockapetris) and Block et ah (U.S. Patent Number 6,192,417; hereinafter Block), as 
applied to the claims above, and further in view of Request for Comment 2236 (Internet 
Group Management Protocol, Version 2; hereinafter RFC 2236). 

21 . Regarding claims 23-24 and 46-47, while Mockapetris discusses maintaining a list of 
multicast members (pg 153 Simulation algorithms, 1st U) Mockapetris is silent as to how a 
multicast member list is updated. In a related art, the Internet Group Management Protocol 
Version 2 provides a protocol for maintaining multicast group membership (RFC 2236 pg 1, 
Abstract 2 nd f) through the use of join (RFC 2236 pg 6, last line) and leave events (RFC 2236 pg 
7, 1st bullet). It would have been obvious to one of ordinary skill in the art at the time of 
invention to incorporate the join and leave events taught by RFC 2236 within the combined RFC 
793 and Mockapetris system in order to allow changes in group membership to be quickly 
reported to the multicast sender (RFC 2236, Abstract 1st U). 



Conclusion 
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22. The prior art made of record, in PTO-892 form, and not relied upon is considered pertinent 
to applicant's disclosure. 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sean Reilly whose telephone number is 571-272-4228. The 
examiner can normally be reached on M-F 8-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess can be reached on 571-272-3949. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 





